Today, there are many applications in which data is broadcast or multicast to a group of individual receivers via some communication channel. Terrestrial and satellite television and radio transmissions are obvious examples. In the Internet, streaming video and audio signals can be broadcast or multicast to individual Internet terminals using the Internet Protocol (IP). In the very near future, technologies such as those defined by 3GPP will allow the broadcasting/multicasting of streaming IP data to mobile handsets. Subscribers will be able to listen to music and watch concerts and football games via their mobile handsets.
With respect to IP, the term “multicast” can be defined as follows:                “An IP technology that allows for streams of data to be sent efficiently from one to many destinations. Instead of setting up separate unicast sessions for each destination, multicast will replicate packets at router hops where the path to different multicast group members diverges. This allows a source to send a single copy of a stream of data, while reaching any number of possible receivers.”        
For a number of reasons, it is often necessary to be able to send multicast signals (it will be appreciated that reference here to “multicast” is only by way of example and that the following discussion applies equally to broadcast signals) in such a way that only authorised receivers can make use of the signals. The nature of the material may make this necessary, for example to prevent children from viewing adult content. In the case of a subscription service, it may be necessary to prevent receivers who have not paid for a service from using a received signal.
In a typical IP multicast scenario, the source entity of the multicast stream acts as a Group Controller (GC). The GC is responsible for establishing and maintaining a secure connection with each user or “receiver” which has registered with the GC to receive the multicast data. According to the latest proposals the Secure Real-time Transport Protocol (SRTP) is likely to be used to provide secure connections in 3G networks. SRTP requires that a Traffic Encryption Key (TEK) be shared between the multicast source and the receivers.
It is the essence of a multicast that only one stream of data is transmitted from the GC and so it is essential that, if the data is to be encrypted, it is encrypted with only a single TEK known to all of the receivers. A simple mechanism to achieve the dissemination of the TEK from the GC to the receivers is for the GC to receive from each receiver, during a registration process, a public key part of a public-private key pair belonging to the receiver. The GC then encrypts the TEK with a receiver's public key and transmits it to the receiver. This is repeated for each receiver. Each receiver can then decrypt the TEK using the private key of their public-private key pair.
Any system must be able to deal with new receivers joining the group and old receivers leaving, in a practical manner. This requires that when new receivers join the group, they are given a new TEK and all existing receivers are notified of the new TEK and informed that this key replaces the previous TEK. When a receiver leaves the group, a new TEK must be generated by the GC and transmitted to all remaining receivers—the departing receiver must not receive, or at least not be able to make use of, the new TEK. With the procedure described in the previous paragraph, each time a new TEK is generated, the GC must generate and send a separate message to each receiver. Especially for services having a large number of subscribers, this places an extremely large processing load on the GC and a large signalling load on the network.
In order to reduce the processing and signalling, a key management principle known as Logical Key Hierarchy (LHK) has been proposed. This is described in detail in IETF Informational RFC2627 “Key Management for Multicast: Issues and Architectures”, Section 5.4. According to this principle, a logical tree structure is created as illustrated for example in FIG. 1. Each node of the tree represents a symmetric encryption key. The key at the top of the tree is the TEK. Other keys in the tree are referred to as LKH keys. Typically, there is a one-to-one mapping between subscribers and the nodes at the bottom layer of the tree. In the tree of FIG. 1, the keys are defined as LKHxy where x represents the tree layer and y is the layer index. The key LKH11 corresponds to the TEK whilst the keys LKH41 to LKH44 are allocated to subscribers M1 to M4 respectively and are referred to hereinafter as Key Encryption Keys (KEKs).
Upon registration of a subscriber with the GC (consider for example subscriber M1 in FIG. 1), the subscriber provides to the GC the public key of a public-private key pair “owned” by the subscriber. The GC then encrypts a unique Key Encryption Key (KEK) with the subscriber's public key. The GC must then generate a new TEK to replace the old TEK. It must also generate new LKH keys (layers 2 and 3) for each of the nodes in the chain between the TEK node and the subscriber node. It then encrypts this new TEK and the other new LKH keys in the chain, with the subscriber's KEK. The encrypted KEK, TEK and LKH keys are combined into a single message (illustrated in FIG. 2) which is unicast to the new subscriber. Once this has been decrypted by the new subscriber, the subscriber can decrypt the LKH keys and the TEK.
The GC must then inform other subscribers of the new TEK. For the other subscriber attached to the same level 3 node as the new subscriber (i.e. subscriber M2), the GC must generate and unicast a separate message for that subscriber, encrypting the new TEK and intermediate keys with the subscriber's own KEK (that subscriber's KEK has not changed). For subscribers M3 and M4 which are connected to the same level 2 node, the GC can multicast a single message containing the new TEK and the new key LKH21, encrypted using the key LKH32, which remains unchanged. For the subscribers M5 to M8, the new TEK is sent in a single multicast message encrypted with the unchanged key LKH22. A similar procedure is followed when a subscriber leaves the group. It will be appreciated the LKH algorithm significantly reduces the number of messages which the GC must multicast in any one rekeying operation.